IBIS Macromodel Task Group Meeting date: 09 May 2023 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora Systems: Dian Yang Cadence Design Systems: * Ambrish Varma Jared James Google: Hanfeng Wang GaWon Kim Intel: Michael Mirmak * Kinger Cai Chi-te Chen * Liwei Zhao Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater * Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Randy Wolff Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: Arpad: Prepare a presentation and statement of the issue for the AMI_GetWave block size with continually adapting models topic. - In progress. See discussion below. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the May 2nd meeting. Ambrish moved to approve the minutes. Kinger seconded the motion. There were no objections. -------------- New Discussion: How to handle the PSIJ Sensitivity BIRD draft and SPIM (BIRD223): Arpad recapped the previous week's discussion. He noted that Walter had shared a presentation on where these proposals would fit into the overall scheme of IBIS, and Kinger had reviewed some slides showing various OEM and EDA organizations who supported SPIM. Walter said having SPIM as a document within the purview of the IBIS Open Forum would be great. However, he reiterated that he thought it would be best if SPIM were a stand-alone document and not part of the IBIS specification itself. He suggested that a new IBIS keyword in the .ibs file itself could be used to link to a SPIM model file. Arpad said that IBIS is generally a modeling language/specification, and it typically does not get involved in prescribing flows and telling EDA tools what to do with the models. He said he could see SPIM describing what data goes into a model, but he would prefer that it avoid getting into descriptions of flows. Bob said that he understood that SPIM is quite different from what is currently in the IBIS specification, but he favored putting SPIM into its own chapter in IBIS itself. He listed several reasons: - Most infrastructure and parser support would be there to apply to SPIM and a new .spim file. - If SPIM referenced a Touchstone file, the ibischk parser could at least check that its terminals were correctly defined. - If it were a separate specification there would be lots of duplication in parser code. So, even though it would mean a fairly large change to ibischk, it would be preferable to dealing with an entirely separate SPIM document. Bob said that it would be nice to hear from some of the vendors that had worked with Kinger and supported SPIM. Arpad and Kinger both recalled that Dian had stated a preference for including SPIM in IBIS itself. Kinger said Dian's reasoning was that the PDN nets should be handled just as the signal nets are currently handled. Ambrish said others in his organization had worked with Kinger. He said that he supported Bob's comments about reusing existing infrastructure. He also noted that the AMI sections of IBIS, for example, describe simulation flows already. Arpad agreed that the AMI flows are one example of a case in which IBIS defines flows. Kinger shared one slide showing a VRM feeding a PDN connected to an I/O buffer driving a channel to an Rx. He said that traditionally IBIS only dealt with the last stage (the Tx output buffer in his slide). Later IBIS extended beyond the I/O buffer and added RLC packaging, and it then introduced S-parameters and coupled RLC models. Now, SPIM wants to extend IBIS to contain a real PDN model to power the buffer. He said they want to treat the PDN as part of the overall system that affects the I/O output. It's a step on the way to having SI and PI support in the same specification and toward convergence of SI/PI. Arpad said that IBIS currently has decent capability for power-aware modeling, but it is limited to the buffers in the simulation. What is missing is the information on the other sources of noise on the supply rails that feed the power-aware IBIS buffer models. He said SPIM is valuable because it can plug that hole and give us more complete power information. Since SPIM is tightly associated with the buffer models we are simulating, he said he was thinking that it might be useful to have SPIM as part of IBIS itself. Walter said he agreed that the SPIM model is part of a [Component] in an .ibs file, just as a Touchstone file is part of an IBIS Interconnect Model, but we don't put the Touchstone specification itself inside the IBIS specification. He noted that timing models are also integral parts of modeling a [Component], but we don't have them in IBIS. Arpad asked whether SPIM is a modeling language of its own. Is it a different language altogether than IBIS, or is it really some new keywords for a new topic. He said that he thought SPIM was more similar to IBIS itself than Touchstone was. Bob agreed that SPIM syntax is similar to existing IBIS syntax. So, he thought it could be included as a chapter in IBIS. Ambrish agreed with Arpad and Bob. However, he noted that AMI is not a separate specification, we merely have an IBIS [Model] that includes an [Algorithmic Model] keyword. Since AMI allows us to include things like executable models (.dlls, .sos), we've already established a precedent for including widely varying things in IBIS. So, why can't we fold SPIM into IBIS if we want to, even if its syntax were very different? Walter suggested that we probably need some sort of vote to pick a direction. The group agreed to hold a straw poll at the next meeting to indicate a preference for including SPIM in IBIS (as is the case for BIRD223) or making SPIM a stand-alone specification. Arpad took an AR to send an email announcing the upcoming straw poll in ATM and noting that a vote will likely take place in the IBIS Open Forum meeting at some point. AMI_GetWave block size with continually adapting models: Arpad said his initial motivation for discussing this topic was a presentation by Fangyi at the February DesignCon IBIS Summit. The presentation discussed an AMI Rx model that was continuously adapting throughout the simulation. The model's only chance to report adaptation results to the tool would be when it returned values following each call to AMI_GetWave. Since the AMI_GetWave function has a parameter for specifying the size of the block of data (wave_size), the value of which is set by the EDA tool, there could be an interaction between the block size chosen by the tool and the time constant of any adaptation. Arpad shared a work-in-progress presentation on the topic. Slide 1: This showed slide 15 from Fangyi's February 2023 DesignCon presentation. The Rx slicer's threshold and offset values could vary from AMI_GetWave call to AMI_GetWave call due to adaptation. Arpad noted that there are PAM4 and more general PAMn AMI Reserved Parameters that can return voltage thresholds and timing offsets from the model at each AMI_GetWave call. Slide 2: This showed the IBIS 7.2 AMI_GetWave definition and the wave_size description. Arpad noted that the EDA tool chooses the wave_size, i.e., the size of each block of data passed to AMI_GetWave. Slide 3: Three possible scenarios: 1. AMI_GetWave takes more than one block to adapt. The model can hopefully carry data across multiple blocks. 2. The block size and the adaptation time constant line up nicely. Everything is fine. 3. The adaptation is much quicker than the block size. Theoretically, the tool could be missing many updates within a given block, since the results can only be reported once per block. Arpad said that in a worst-case example of scenario 3, the tool might end up with a closed eye because it was using incorrect threshold values for portions of the large data blocks. Walter addressed the 3 scenarios. For scenario 1, he said that if the model works differently for different block sizes, then it's a bug in the model. For scenario 2, he agreed that everything is fine already. For scenario 3, he said he thought there were 2 possible solutions: 1. Tell the user not to make the block size larger than XXX bits, or adaptation won't work. This could be provided as documentation with the model. 2. Or, is this just a problem with waiting out the initial convergence? The Ignore_bits AMI Reserved Parameter can be used to cover this case. After some initial convergence period, it's probably going to be stable and you won't have a block size related problem. Just make Ignore_bits large enough to cover the initial convergence period. Walter said he didn't see any other mechanism for scenario 3. AMI_GetWave should converge to steady state values after Ignore_bits. Alternatively, if something like ISI or data dependent effects can still lead to large shifts in thresholds or offsets after Ignore_bits, then the model maker just has to tell the user to use a smaller block size. Arpad said this issue was analogous to issues with samples per bit (sample_interval). The specification says AMI models should work with any sample_interval, but in practice some models require a power of 2 for samples per bit. The user's guide may tell the user to use 16, 32, 64, etc., samples per bit, for example, but he said he had run into issues with improper settings of sample_interval in the past. He said he wished we had an AMI Reserved Parameter that could provide that information to the EDA tool, too. Walter said the model can use the msg parameter to return an error message string if it has a problem to report. Ambrish said that we don't need to change the specification just because some users aren't reading their models' documentation. He agreed with Walter's suggestion that Ignore_bits should be sufficient to cover this issue, as the values should settle over time if the model converges properly. Walter asked, what might cause it to vary over the longer term after initially settling? Arpad said a bit pattern with non-zero DC component could move the thresholds around within a certain range even after Ignore_bits. Walter asked what could cause that. He said he thought it would be hard for an LTI Tx model to provide DC drift. Arpad said imbalanced '1' and '0' bits could do that, but he'd have to think about the LTI part of the question Arpad asked whether there was any interest in pursuing this topic. He asked whether he should continue developing his slides on the topic. Curtis noted that the BCI_Message_Interval_UI AMI Reserved Parameter provides information, in the back-channel communication context, analogous to what Arpad was describing. Walter and Ambrish said they thought Ignore_bits was probably sufficient for any real world modeling scenarios. Ambrish suggested the topic could be tabled for now and reconsidered if we see users and model makers running into trouble. - Kinger: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. New ARs: Arpad: Send an email announcing the straw poll ATM vote on whether to include SPIM in the IBIS specification itself or make it a stand-alone specification. ------------- Next meeting: 16 May 2023 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives